Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/generators/built-in/process-api-reference-generator.ts`:
- Around line 93-109: Update the generate method signature on class
ProcessApiReferenceGeneratorImpl to match the DocumentGenerator interface by
replacing the parameter type readonly unknown[] with readonly ExtractedPattern[]
and import ExtractedPattern from the types module; specifically change
generate(_patterns: readonly unknown[], _context: GeneratorContext) to
generate(_patterns: readonly ExtractedPattern[], _context: GeneratorContext) and
add the corresponding import so the class (ProcessApiReferenceGeneratorImpl)
explicitly conforms to the interface.

In `@src/renderable/codecs/reference.ts`:
- Around line 943-949: The TOC is being inserted after the first separator
(firstSepIdx) which can be the separator added right after config.preamble,
causing the TOC to appear before the generated intro; change the insertion logic
to locate the separator that follows the intro block instead of the very first
separator. Specifically, when tocBlocks produced by
buildTableOfContents(sections) is non-empty, find the index of the intro block
(e.g., const introIdx = sections.findIndex(s => s.type === 'intro') or otherwise
compute the intro boundary) and then find the separator after that (e.g., const
sepAfterIntro = sections.findIndex((s, i) => i > introIdx && s.type ===
'separator')), and splice tocBlocks at sepAfterIntro + 1 (falling back to
firstSepIdx or end if no intro/separator found); update the code paths that
reference firstSepIdx, tocBlocks, buildTableOfContents and config.preamble
accordingly.
- Around line 1797-1809: The hardcoded byStatus label in
buildMasterDatasetViewsDiagram uses an incorrect vocabulary; update the byStatus
node string (the entry with byStatus["byStatus<br/>(... )"]) to list the
canonical lifecycle names in the correct/process-guard order (roadmap, active,
completed, deferred) so the diagram matches the dataset and the FSM rules
(roadmap → active → completed, deferred → roadmap).
- Around line 614-618: The preamble field from ReferenceDocConfig is only
honored inside decodeProductArea, so createReferenceCodec({ preamble, ... })
drops preamble for the normal decode path; to fix, apply the same
preamble-handling logic used by decodeProductArea in the standard decode branch
as well: extract/merge the preamble from the config and prepend or merge it into
the dataset/content before continuing with the regular decode flow. Update
createReferenceCodec (or the decoder entrypoint) so both branches (productArea
and non-productArea) invoke the preamble application step, keeping
decodeProductArea unchanged and reusing its preamble behavior.

---

Outside diff comments:
In `@src/renderable/codecs/reference.ts`:
- Around line 664-701: The code currently deduplicates shapes using only
shape.name (seenNames), which collapses distinct shapes with the same name from
different files/modules; change deduplication to use a source-qualified key
(e.g., `${shape.name}::${shape.source || shape.filePath || shape.moduleId}`)
everywhere name-only deduplication is used (the seenNames set and any other
place that checks shape.name, such as the selector merge and the include-tag
merge and the similar block around buildShapeSections and the later 876–907
region). Replace the Set<string> seenNames with a Set of these composite keys
(rename to seenKeys), compute the key via a small helper (e.g.,
makeShapeKey(shape)) and use that helper whenever adding/checking so distinct
declarations with the same name do not collide while preserving current merge
logic around extractShapesFromDataset, filterShapesBySelectors, dataset.patterns
and buildShapeSections.

---

Duplicate comments:
In `@src/renderable/codecs/business-rules.ts`:
- Line 434: The NEXT_HEADER_PATTERN regex incorrectly uses the ^ anchor inside
the alternation causing indented table rows to miss matches; update
NEXT_HEADER_PATTERN so the pipe branch matches after optional whitespace (e.g.,
replace /\n\s*(\*\*[A-Z]|^\|)/m with a pattern that either removes the ^ or uses
a lookahead such as /\n\s*(\*\*[A-Z]|\|)/m or /\n(?=\s*(\*\*[A-Z]|\|))/m so that
'\n  | table |' is correctly recognized; change the constant NEXT_HEADER_PATTERN
accordingly and run tests that cover indented table rows and header detection.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@delivery-process/specs/cli-recipe-codec.feature`:
- Around line 116-126: The invariant describes RecipeExample.commands as an
array of strings but the spec and stubs use per-step metadata via RecipeStep,
creating an inconsistency; update the invariant so CLI_SCHEMA's recipes field
defines RecipeGroup[] where each RecipeExample.commands is RecipeStep[] (not
string[]), and ensure the text mentions RecipeStep fields (e.g., command string,
optional comment, optional expectedOutput) while clarifying that this extension
is additive and does not change existing CLIOptionGroup types; adjust any
references to RecipeExample.commands accordingly to align the contract with the
RecipeStep model.

In `@delivery-process/specs/docs-consolidation-strategy.feature`:
- Around line 86-91: Update the feature scenarios so they expect generated
public reference output under docs-live/ instead of docs/; specifically change
the scenario "Convention tag produces a generated reference document" (and the
other similar scenarios referencing generated reference docs) to assert a
detailed docs-live/ file and a compact _claude-md/ file are produced, while
leaving the rest of the checks (that both contain the convention content
extracted from source JSDoc and that a ReferenceDocConfig entry matches the
convention tag) unchanged.
- Around line 139-159: The retention rule conflicts with the scope table: the
invariant names SESSION-GUIDES.md, GHERKIN-PATTERNS.md, PROCESS-API.md, and
PUBLISHING.md as fully manual while Phases 39–43 mark them as
trimmed/hybrid/relocated; update the spec so the invariant and the acceptance
Scenario align with the scope table. Either remove those filenames from the
"fully manual" list (leaving only true-manual docs like METHODOLOGY.md) or amend
the scope table/Phases 39–43 entries to mark them as retained; ensure the
Scenario "Retained documents have no generated equivalent" and the check for
ReferenceDocConfig reflect whichever choice.
- Around line 18-30: The document inconsistently references the number and
numbering of phases (mentions "6-phase consolidation" and "10 phases", and the
scope table lists "phases 1-6 plus 37-43"); pick the intended phase count
(either 6 or 10) and make all references consistent: update the summary header
phrase ("6-phase consolidation"), the later sentence that says "10 phases", and
the scope table entries (remove or renumber "37-43" and ensure it lists the
correct phase range such as "phases 1–6" or "phases 1–10"), and scan the nearby
section (the content around the current lines 33–47) to fix any remaining
mismatched mentions so the roadmap reads with a single, consistent phase count
and numbering.

In `@delivery-process/specs/docs-live-consolidation.feature`:
- Around line 91-95: Scenario title "docs-generated/ is empty after standard
generation" overstates the verification because the step "Then docs-generated/
contains no .md files" only checks for .md files; update either the title or the
assertion: either rename the scenario to "docs-generated/ contains no .md files
after standard generation" or replace the step with an explicit check that the
directory is absent or empty (e.g., assert "docs-generated/ does not exist" or
"docs-generated/ is empty") so the scenario's title and step(s) match the
intended post-consolidation state.
- Around line 59-64: The assertion at the end of the "Reference docs are
generated into docs-live/reference/" scenario is guarding the wrong legacy path;
change the negative check that currently verifies "docs-generated/docs/ does not
exist" to instead assert that "docs-generated/reference/ does not exist" so the
scenario fails if stale reference output is still emitted to the legacy
reference directory.
- Around line 66-72: The spec rule in docs-live-consolidation.feature conflicts
with the implementation: delivery-process.config.ts still routes the
claude-modules generator to the repo-root _claude-md, while the rule insists all
compact files live under docs-live/_claude-md/. Either narrow the feature rule
to only apply to architecture reference summaries (architecture-codecs,
architecture-types) or update delivery-process.config.ts to route the
claude-modules generator into docs-live/_claude-md/ (and adjust any references
to “_claude-md/” in the PR summary/spec accordingly); locate the rule text in
docs-live-consolidation.feature and the claude-modules generator config in
delivery-process.config.ts to apply the chosen change.

In `@delivery-process/specs/enhanced-index-generation.feature`:
- Around line 39-42: The acceptance criteria are contradictory: the Scope table
lists sources as “File system scan plus MasterDataset” while DD-2 and the
`documentEntries` behavior describe a static, no-I/O codec; pick a single source
model and make both places consistent. Decide whether the inventory is generated
from a FileSystem scan + MasterDataset or from static `documentEntries` (no
I/O), then update the Scope table entry and the DD-2 wording (and any scenario
text referencing `documentEntries`) to match that choice; also apply the same
change to the other affected scenario lines (the related entries around lines
61-62) so all scenarios and acceptance criteria are aligned.

In `@delivery-process/specs/procedural-guide-codec.feature`:
- Around line 214-220: The scenario asserts the wrong generated filename: the
ProceduralGuideCodec with ReferenceDocConfig produces
docs-live/reference/ANNOTATION-REFERENCE.md, not ANNOTATION-GUIDE.md; update the
feature scenario (the "Two separate guide files are generated" scenario) to
expect docs-live/reference/ANNOTATION-REFERENCE.md (keep the
SESSION-WORKFLOW-GUIDE.md expectation) so the test matches the configured
annotation output filename generated by ProceduralGuideCodec/ReferenceDocConfig.
- Around line 38-43: The feature text mixes two incompatible pipelines for
checklists and decision trees (SessionGuidesModuleSource vs docs-sources/*.md
loaded via loadPreambleFromMarkdown()), so pick one pipeline and update the spec
to reference only that source and its acceptance rules; e.g., if you choose
SessionGuidesModuleSource, change Solution/Scope and Rule 1/4 to state
checklists and decision trees are extracted from SessionGuidesModuleSource and
preserve the SESSION-GUIDES.md invariant, or if you choose docs-sources/*.md,
update Rule 2 and any references to extraction to use loadPreambleFromMarkdown()
and its acceptance criteria, and ensure all other affected blocks (lines noted:
54-67, 112-123, 152-190, 233-239) are made consistent with the single chosen
pipeline.

In `@delivery-process/stubs/cli-recipe-codec/cli-recipe-generator.ts`:
- Around line 297-313: The comment incorrectly points readers to
delivery-process.config.ts as the registration site; update the preamble to
state that although generatorOverrides in delivery-process.config.ts can
override outputDirectory, the actual registration for the "cli-recipe" generator
is done programmatically following the createProcessApiReferenceGenerator()
pattern in the built-in codec-generators registration module (i.e., where
built-in codec generators are registered), so change the example and wording to
reference that programmatic registration hook and remove the misleading
generatorOverrides-only claim.
- Around line 103-177: The functions buildRecipeSections and
buildNarrativeSections (and the generator exports
generate/createCliRecipeGenerator) are currently untyped (unknown) and must be
updated to the actual generator interfaces; change their signatures to use
SectionBlock[] for section arrays, implement generate(_patterns: readonly
unknown[], _context: GeneratorContext): Promise<GeneratorOutput>, and ensure
createCliRecipeGenerator(preamble: readonly SectionBlock[]): DocumentGenerator
returns an instance of CliRecipeGeneratorImpl which implements
DocumentGenerator; import and use the canonical types SectionBlock,
GeneratorOutput, DocumentGenerator, and GeneratorContext from the project's
types so the stub matches the real implementation at
src/generators/built-in/cli-recipe-generator.ts.

In `@delivery-process/stubs/cli-recipe-codec/recipe-data.ts`:
- Around line 109-113: COMMON_RECIPES, SESSION_WORKFLOW_NARRATIVES, and
EXAMPLE_PREAMBLE currently export concrete example payloads; remove those real
data objects from the module and replace each exported symbol with a stub that
throws new Error('PatternName not yet implemented - roadmap pattern') (e.g.,
export const COMMON_RECIPES = () => { throw new Error('COMMON_RECIPES not yet
implemented - roadmap pattern') }, or export const COMMON_RECIPES = (() => {
throw new Error('COMMON_RECIPES not yet implemented - roadmap pattern') })() )
so downstream code cannot import real examples; move the concrete examples
(startingASessionRecipe, findingWorkRecipe, narrative arrays, preamble text)
into JSDoc or a separate Markdown example section in the file rather than the
export surface and apply the same throw-only pattern to
SESSION_WORKFLOW_NARRATIVES and EXAMPLE_PREAMBLE.

In `@delivery-process/stubs/cli-recipe-codec/recipe-schema.ts`:
- Around line 211-244: Remove the duplicate, weakened CLISchemaExtended
interface and instead alias the canonical CLISchema: import the original
CLISchema (from src/cli/cli-schema.ts) and replace the interface declaration
`export interface CLISchemaExtended { ... }` with `export type CLISchemaExtended
= CLISchema;`, ensuring you no longer re-declare `globalOptions`,
`outputModifiers`, `listFilters`, `sessionOptions`, `recipes`, or
`commandNarratives` here so the concrete types from the source-of-truth are
preserved.

In `@delivery-process/stubs/enhanced-index-generation/index-codec-options.ts`:
- Around line 108-113: Update the JSDoc for documentEntries to remove any claim
that the codec merges entries with auto-discovered/generated documents from
MasterDataset; instead state that documentEntries is a static, explicit contract
(no filesystem or MasterDataset discovery), and clarify that MasterDataset
exposes pattern views rather than a document inventory so it is not used as a
source of documentEntries. Ensure the comment references the symbol
documentEntries and MasterDataset so readers know the intended static-only
contract and correct source-of-truth.

In `@delivery-process/stubs/enhanced-index-generation/index-codec.ts`:
- Line 101: The module currently invokes createIndexCodec during top-level
initialization by exporting IndexCodec = createIndexCodec(), which throws on
import; stop calling the throwing stub at module load by removing the immediate
invocation and instead export the factory or a thunk (e.g., export
createIndexCodec and/or export getIndexCodec/getIndexCodecInstance that calls
createIndexCodec at call time) so callers can opt-in to construction; update any
references to IndexCodec to call the factory/getter rather than rely on a
preconstructed instance.
- Around line 86-88: The createIndexCodec stub currently returns unknown and is
eagerly instantiated by export const IndexCodec = createIndexCodec(), which
causes import-time failure; change the signature of createIndexCodec to return
z.ZodCodec<MasterDatasetSchema, RenderableDocumentOutputSchema> (matching the
real contract and supporting .decode calls in generate.ts) and replace the eager
export with either no eager instantiation (remove export const IndexCodec) or
export a safe non-throwing placeholder codec from createIndexCodec that
implements decode (a minimal pass-through or runtime-safe stub) so the module
can be imported without throwing; update references to IndexCodec to call
createIndexCodec() lazily if needed.

In `@delivery-process/stubs/enhanced-index-generation/index-preamble-config.ts`:
- Line 211: Update the stale filename entry in the index preamble array: replace
occurrences of 'PUBLISHING.md' with the new 'MAINTAINERS.md' in the list items
(e.g., the array entry currently showing ['PUBLISHING.md', 'Maintainers',
'Release -- npm publishing']), and also scan and update the other matching
entries referenced (around the second occurrence at lines ~393-395) so the
generated index points to MAINTAINERS.md instead of the removed PUBLISHING.md.
- Around line 104-106: The SectionBlock 'table' variant is using a non-existent
headers property; update each table block (e.g., the object with type: 'table'
as const) to provide a columns property instead of headers so it matches the
SectionBlock table schema in src/renderable/schema.ts—replace headers: [...]
with columns: [...] for the blocks around the current change and the similar
block at the other occurrence (lines referenced in the review).

In `@delivery-process/stubs/error-guide-codec/enhanced-validation-options.ts`:
- Around line 118-126: The constant ENHANCED_DEFAULT_OPTIONS is typed with
Required<EnhancedValidationRulesCodecOptions>, which promotes the inherited
optional limits (from BaseCodecOptions/CodecLimits) to required but the literal
omits limits; fix by either adding a proper limits: CodecLimits value to
ENHANCED_DEFAULT_OPTIONS or change the typing to use "satisfies
EnhancedValidationRulesCodecOptions" so limits remains optional; update the
declaration for ENHANCED_DEFAULT_OPTIONS and ensure references to
EnhancedValidationRulesCodecOptions, BaseCodecOptions and CodecLimits are used
to construct or validate the limits value if you choose to add it.
- Line 40: Update the import for BaseCodecOptions in
enhanced-validation-options.ts to point to the repo root (use
../../../src/renderable/codecs/types/base.ts or
../../../src/renderable/codecs/types/base.js) so the type resolves correctly,
and fix the ENHANCED_DEFAULT_OPTIONS constant (typed as
Required<EnhancedValidationRulesCodecOptions>) by either adding a concrete
limits property of type CodecLimits to the object literal or loosening the type
wrapper (remove Required<> or make limits optional) so the missing limits field
no longer causes a TypeScript error; reference BaseCodecOptions,
EnhancedValidationRulesCodecOptions, ENHANCED_DEFAULT_OPTIONS, limits, and
CodecLimits when making the change.

In `@delivery-process/stubs/error-guide-codec/error-guide-config.ts`:
- Around line 215-237: Remove or reword the outdated registration snippet in the
comment block: the CONVENTION_VALUES example that lists 'process-guard-errors'
is obsolete because that value already exists; update the comment in
error-guide-config.ts to reflect the current state (either delete the entire
example block or replace it with a short note stating that
'process-guard-errors' is already included in CONVENTION_VALUES) and ensure
references to CONVENTION_VALUES and 'process-guard-errors' remain accurate.
- Around line 200-206: The mermaid node name "detectChanges" is ambiguous
compared to the exported functions used elsewhere; update the diagram to match
the real API names (e.g., replace the node with detectStagedChanges and/or
detectBranchChanges) or explicitly relabel it as a generic step like "change
detection" so readers won't assume a callable API; ensure the connected nodes
(deriveProcessState, validateChanges, ValidationResult) remain unchanged and the
label you choose aligns with the preamble/table terminology.

In `@delivery-process/stubs/procedural-guide-codec/load-preamble.ts`:
- Line 111: The import for SectionBlock in the procedural-guide-codec stubs is
using the wrong relative path; update the import statement that currently reads
"import type { SectionBlock } from '../../src/renderable/schema.js';" to use the
correct relative path "../../../src/renderable/schema.js" in all three
procedural-guide-codec stub files (the load-preamble, procedural-codec-options
and procedural-codec stubs) so the SectionBlock type resolves to the actual
schema module.

In `@delivery-process/stubs/procedural-guide-codec/procedural-codec-options.ts`:
- Around line 63-73: The Annotation Guide column in the
procedural-codec-options.ts stub is out of sync with the actual
ReferenceDocConfig used in delivery-process.config.ts; update the Annotation
Guide fields to match the real config by setting title to "Annotation Reference
Guide", setting conventionTags to ['annotation-system'], removing or leaving
includeTags empty (no includeTags), and changing claudeMdSection to 'annotation'
(verify docsFilename/claudeMdFilename remain correct) so the codec routes this
document through the annotation extraction path.